As a foreword and disclaimer, I am not a network security engineer. I am self-taught and motivated to be as accurate as possible, but I have neither infinite time nor infinite intelligence. Do your own research, convince yourself that your process is correct.

My use-case for Meshtastic is complementary to tools like Reticulum, which are more capable yet harder to learn and share with my friends and family. Meshtastic is a low barrier-to-entry method of communicating during emergencies, and it shouldn't be treated as a modern cryptographic solution for highly-sensitive communications.

Downlink: to retransmit traffic from MQTT to LoRa (radio) channels.

Uplink: to publish LoRa packets from radio channels to an MQTT broker.

For me, MQTT is what turns Meshtastic from a curiosity with minor utility into a practical, useful everyday tool. MQTT is a lightweight publish-subscribe messageboard with simple built-in credential management and access control that can run on very modest hardware, like a Raspberry Pi. The complexity of a setup can have a huge range, but a broker for Meshtastic is a simple one.

However, some users are annoyed at the usage of MQTT brokers in their local mesh, as older node firmware versions fail to tag MQTT traffic, leading to confusion on the resilience of the network in the event that internet fails. While this is an unfortunate effect of having old node firmware in the wild, the underlying issue is the way that MQTT brokers are utilized in the mesh.

Currently, most users think of MQTT as a way to knit together areas of the mesh that are too far apart to have a reliable radio link. This is technically accurate, but also too general. I believe the optimal way to utilize MQTT is in private networks; ones which want a degree of communication redundancy, but where the presence of the broker does not adversely affect the broader mesh.

To set up a private broker in this way, it must have private credentials for connection. Sharing the broker with external participants should be avoided unless the remote participants do not downlink the MQTT traffic to their local radio mesh; or minimally they follow the one-hop rule (see Meshtastic documentation). Furthermore, in most situations, the public broadcast channel (i.e. "LongFast") should not be downlinked from the MQTT broker to any local radio meshes.

By keeping the broker connections private, and precluding public broadcast from the broker entirely, you can utilize an MQTT broker to achieve significantly improved communication redundancy while largely not affecting the wider mesh network.

If you are like me, you probably live in one place most of the time. A house, apartment, or an RV; all of these make for a good home-base to run an always-on MQTT broker.

If you can add a stationary Meshtastic node at your home base which is directly connected to your MQTT broker, ideally via USB serial or Ethernet, it makes sense to downlink your private MQTT traffic through this node.

Set up a private channel that all of your core nodes share. These would be nodes that are relatively secure; for instance:

Don't add a private channel to a node that does not need it. If you have a relay node up in a tree somewhere, it doesn't need to know the private security key (PSK) associated with your private channel; if someone else got ahold of that node, they could not only begin to decrypt your traffic from then on, but they could also decrypt all prior traffic that they had recorded. Additionally, remove any private channel credentials from nodes which are decommissioned or which change roles from a "core" role to something more extraneous.

Please note that I have not fully considered the proper way to set up permanent multi-site links, i.e. if you have two long-term homes or you have a permanent link to your parents' home. In my estimation, there are better solutions than MQTT for this.

For most users, my setup is overcomplicated. I will go through it quickly, and then make more efficient recommendations.

I currently have an MQTT broker in a low-security VLAN (virtual local area network) called my "IOT VLAN". This broker has port 1883 port-forwarded to the public internet, and it has private credentials to access the broker. I bought a domain and manually set up my DDNS (dynamic domain name system) using OPNsense through Cloudflare. There are guides on this, but it is not the simplest method to get started. Still, this general setup allows any of your internet-connected nodes to connect to the broker when/if the internet (and the public DNS servers) are up and running.

Aside from the IOT broker, I also have an instance of HomeAssistant running in my LAB VLAN, which instantiates another MQTT broker. On the second broker in this higher-security VLAN, I subscribe to topics on the IOT broker, allowing me to use Meshtastic traffic for home automation purposes, but without exposing the LAB network's MQTT ports to the internet. There are other ways to accomplish this through the various Meshtastic/MQTT add-ons and integrations; this is just part of my setup, anyway.

If you don't want to spend weeks/months learning the details of networking security, there's a simpler option. Don't expect it to be easy, though; the process is still rather involved.

1) If your WiFi router doesn't include a free DDNS service, buy one that does, and enable it.

2) Set up an always-on server of some kind; this could be on a Raspberry Pi or on an old laptop. In general, Linux is a better platform for high-reliability servers, but Windows is also supported.

3) Install [Mosquitto](https://mosquitto.org/) on that server/container, and read the documentation for adding credentials (username/password) to the broker. Also, enable the default port 1883 (again, read the docs).

4) On your internal network, try to connect to the broker using a tool like [MQTTX](https://mqttx.app/) on your PC. You'll need to input the details of the connection, which should look something like this:

- the local IP address of your MQTT broker: i.e. 192.168.X.XX

- the MQTT port: 1883

- the Username/Password you configured in Mosquitto

- a default topic, i.e. 'msh'

5) Once you've confirmed that your broker is working correctly internally, in your router settings, forward port 1883 from your Mosquitto broker's IP address to the public internet.

6) Now, try to connect to your broker from outside of your network (i.e. over cellular internet). This will be using the DDNS address you set up in setup one! i.e. "mynetwork.tplinkdns.com"

If all goes well, you're essentially done. There could be some additional work to do with devices which switch between external/internal networks, as the domain name of your broker will change (and you will disconnect from the broker when this happens). Setting up your own internal DNS is not difficult, but it's a topic for another time. Look up "pi-hole DNS" for a quick way to get started. You may also be able to configure your router to manually map the Mosquitto server's IP address to match your DDNS hostname.

Even with all of my confidence in my current setup, I believe that Meshtastic's MQTT -- radio link compatibility has been overly simplified in the node firmware.

For networks which have both links (MQTT and LoRa), with multiple nodes capable of uplinking radio traffic to a broker and even one node capable of downlinking it back to the LoRa channel, the downlink node seems to do so without considering wait times or collision mechanics. There are two basic scenarios here:

1) The downlinking node cannot hear the radio transmission, but only receives the packet via MQTT.

2) The downlinking node receives the radio transmission and the MQTT packet simultaneously.

In both scenarios, the downlinking node should wait (similar to how the ROUTER_LATE device setting functions, but possibly with an even longer wait period) until any other retransmitting nodes have had a chance to send before downlinking. This would allow for radio traffic to appropriately be untagged as "forwarded via MQTT", which is critical for wide area networks which have some routers dropping MQTT traffic.

I haven't proofread this particularly well, and I don't write that often, but I hope that this can be useful to someone. If you noticed errors, or you have a better way of doing things, please share! I'm fumbling through this myself, and I could use a second set of eyes.

Thanks for reading. May your path remain lit.

I'm currently looking into a workaround for the issues mentioned in the final section; I believe it's possible to use a more advanced MQTT broker (like EMQX) to build-in a publishing delay.

Hello, I found your blog post very interesting. I'm always curious about others use cases for Meshtastic, Reticulum etc.

Hi Off Grid! Thanks for reading :) I'm slowly but surely learning the basics of infosec, and it's encouraging to have other eyes on my work to critique it when appropriate. As an aside, I have successfully implemented the publish delay mechanism mentioned at the bottom of the post, but it required a couple of non user-friendly steps. The community release of EMQX was unfortunately only half of the solution; they don't include the "Topic Rewrite" feature in the community edition, which would have made the process much simpler, but I added a few lines to the Meshtastic firmware which automatically prefixes any MQTT publish messages with the keyword necessary for EMQX to delay the publishing. If anyone is interested, I'm more than glad to share, though I'll likely be updating the blog post itself soon. :D

Testing the max length function... -∿ < Hello! This is output from micron Micron generates formatted text for your terminal -∿ < Nomad Network supports a simple and functional markup language called micron. If you are familiar with markdown or HTML, you will feel right at home writing pages with micron. With micron you can easily create structured documents and pages with formatting, colors, glyphs and icons, ideal for display in terminals. >>Recommendations and Requirements While micron can output formatted text to even the most basic terminal, there's a few capabilities your terminal must support to display micron output correctly, and some that, while not strictly necessary, make the experience a lot better. Formatting such as underline, bold or italics will be displayed if your terminal supports it. If you are having trouble getting micron output to display correctly, try using gnome-terminal or alacritty, which should work with all formatting op..

Fantastic read, I've been looking into an MQTT broker to expand my private network. Just working on some resilience infrastructure to coordinate storm recovery and outage scenarios. Very good stuff here, thanks for the work and effort you've put in!

Your Name:

Your Comment: